Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


System Design Considerations

The following sections distinguish between the hot, or online, backup and the cold, or offline, backup and provide several hints on how to design your system for optimal backup performance. Some of these hints may or may not apply to your configuration. It is up to you to determine which apply to your system.

Cold Database Backup

In a cold database backup, the database is shut down and no users have access to the system. This situation is the best case for backup because it is up to the database administrator to determine how the database is backed up and the data access patterns. This control makes it easier to optimize the system than is possible with a hot, or online, backup.

Because you have control over how the disks are accessed in a cold backup, you should design the backup procedure to take maximum advantage of sequential disk I/O to the backup storage device. By making the I/Os sequential, you can achieve a much higher throughput rate. The following sections examine how you can achieve sequential I/O.

Physical Data Access

The way to guarantee sequential I/O is simply to allow only one backup stream at a time to access a set of disks. If you use Oracle disk striping or RAID arrays, the concept is the same. For each disk drive or volume of disks, serialize the backup of the data files so that only one backup process at a time accesses it. Because multiple RAID volumes may exist on your machine, you should parallelize the backup operation on these devices by backing up all the disk volumes simultaneously.

For a cold backup, it is not necessary to change the design of the system because you eliminate all other database accesses to the data files by shutting down Oracle. By designing the backup procedure, you should be able to achieve optimal I/O rates.

Hardware/Software Considerations

When choosing hardware and software for backup, make your decisions with the following issues in mind:

  Fast tape device. The speed of the backup is most likely limited by how fast you can write to tape.
  Fast network device. If you are backing up the system through a network, make sure that your network hardware is not a limiting factor.
  Optimal software. Some third-party backup vendors are much faster than others. Make sure that you are getting good software for your platform.
  Optimal tuning. By adjusting values such as the block size you are using, you may be able to optimize disk and tape speeds.
  Compression. If you use compression, make sure that you are using an optimal compression method that has both high performance and a good compression ratio.

By optimizing all these areas, you should be able to achieve an excellent backup rate. Shop around for tape devices; you will find that some of the new tape devices have incredible performance characteristics.

Hot Database Backup

The hot database backup is more complex than the cold database backup. In the cold data-base backup, there is usually no other disk activity besides the backup itself; in the hot database backup, there is significant disk activity to the other data files in the system. To optimize the backup, there are several things that can be done, all of which happen at the database and hardware design stage.

The optimizations you can make all have the goal of shortening the amount of time data files must be taken offline for the backup. These optimizations can include the following:

  Isolate sequential I/O. This may or may not be possible or effective. You should not put only one tablespace on a disk volume unless the performance is sufficient during normal operation.
  Use temporary backup volumes to compensate for slower components such as network or tape. If possible, back up your database to a local disk. After you bring your users back online, you can begin the task of backing up those files to the network or to tape.
  Use high-speed, isolated links between the database server and the backup server. By backing up the database using an isolated link, you can improve the performance of the backup as well as limit the effect the backup has on the network bandwidth.
  Split up backups. It is not necessary to perform the entire backup at one time. If necessary, break the backup across several days.

These optimizations can help speed the backup process. Not all these hints may apply to your configuration; use the ones you think will benefit your particular system.

Physical Data Access

The following sections describe a few of the ways you can better configure your system to optimize the backup process. Some of the methods described may be impractical for your installation because of the additional hardware requirements. But by understanding the concepts, you may be able to improvise a method that better suits your particular installation.

Isolating Tablespaces

By isolating data to a single tablespace per disk volume, you can take advantage of the sequential nature of the backup’s I/O access patterns (assuming that very little read activity is occurring). Although this may seem to be a good way to get high-speed sequential I/Os from the disks, the system may suffer in the long run.

Because the tablespaces must also be used during the normal operation of the system, it may not be wise to limit the disk volumes to one tablespace. When you do this, you may have disk volumes that are either overutilized (causing an I/O bottleneck) or underutilized (causing some other disk volume to be overutilized).

For many applications, the best way to balance I/Os is to spread the tablespaces over all the available disk volumes. By having all the tablespaces on all the disk volumes, you have the best chance of balancing the I/Os, even if some tablespaces are more active than others.

Isolating the tablespaces so that you have only one tablespace per disk volume may help backup performance; however, the overall performance of the system may suffer. I cannot recommend that you have only one tablespace per disk volume unless backup time is more critical than general RDBMS performance.


NOTE:  Even if you have only one tablespace per disk volume, because the backup only defers to the SGA in cache reads and writes, there is no guarantee that the access to the disks will be sequential if there is read activity on the tables within the tablespace that is being backed up.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.